I'm not sure what we gain by renaming these files. If we offered the user the option to switch between OAI and Anthropic API then we'd use an Anthropic API client and not the OpenAI API client right? Similarly if we expose an OpenAI endpoint for some Leo functions then we'd most likely use the existing client.
But I don't think we'd grow the OAI client files to support two different API styles.

I'm not sure what we gain by renaming these files. If we offered the user the option to switch between OAI and Anthropic API then we'd use an Anthropic API client and not the OpenAI API client right? Similarly if we expose an OpenAI endpoint for some Leo functions then we'd most likely use the existing client. But I don't think we'd grow the OAI client files to support two different API styles.

The OAI files are currently serving OpenAI, Ollama, Azure endpoints and more (each of which partially implement the OpenAI API spec, but with subtle differences). Rather than potentially making ongoing changes within the "OpenAI" files, I'm proposing we rename the existing files to something more generic (i.e., "BYOM" files), and then (as needed) create service-specific files for particular providers. As you suggest, this would mean the introduction of files for Anthropic, Perplexity, and more (which is what I had planned as a follow-up on this PR).

The reason I went this route (as opposed to simply creating an entirely new anthropic_api_client.cc) was to maintain a common API client with distinct methods for handling headers and responses. Rather than creating largely redundant code, I thought it would be better to instead enable us to provide provider-specific methods for constructing headers for requests, as well as handling responses. That said, I'm more than happy to take an approach that is more consistent with our current solution, and keep that logic encapsulated at the provider class level, creating distinct *_api_client.cc files, etc.

Your call :)

We have an established pattern of providing distinct API Client classes for different endpoints. While it is presently the case that our OpenAI Client handles OpenAI, Ollama, and more, it is still quite basic and straight-forward. The goal of this PR was to introduce alternative branches of logic (specific to particular providers) for constructing requests, and handling responses. It is probably wise not to deviate from the current path of keeping platform-specific logic confined to API Client classes, rather than introducing smaller platform-specific classes aimed at handling requests-construction and response-parsing alone. As such, I'm going to close this issue and focus instead on introducing additional API Clients for presently-unsupported providers.